This potentially breaks i18n workflows because it mutates the field's label which is implicitly used as the translation key. Since the concept is stored under the field's meta, this can safely be done within the number component post label translation; something like:

<NumberInput
      id={field.id}
      label={<FieldLabel field={field} customLabel={t(field.label) + extractFieldUnitsAndRange(field.meta.concept)} />}

@samuelmale thanks, moved the units and range to the number component. Also for a concept that defines min but not max it looks like

leaving critical alone for now

We should harmonize the view here to what we're doing here, which is >= 0 or <= 100 things like that. (Note that "Min" is hard to support because now that's a string that needs to be translated).

unfortunately it splits the label onto a new line, but the format should match the chart lab result format

I mean, that was always going to be a possibility... This just made it apparent for that one case.

@ibacher when is it necessary to use hiCritical vs lowCritical?

All of the values that aren't lowAbsolute and hiAbsolute are basically only for displaying concerning results (outside the normal range, but inside the critical range) or critical results (outside the critical range, but within the absolute range). Does that make sense? lowAbsolute and hiAbsolute should be rare and only in cases where the value can never exceed that range (e.g., SpO2 is a percent, so it's always between 0 and 100; heights and weights should never be a negative number, things like that).

But we can handle critical icons in a separate PR.